Design in an organizational context - an experiment

knowledge Relevant structures on users’ present work (2) Visions and design proposals (5) Overview of technological options (4) Concrete experience Concrete experience with users’ present work (1) Concrete experience with the new system (6) Concrete experience with technological options (3) 7 Bødker and Kensing: DESIGN IN AN ORGANIZATIONAL CONTEXT: AN EXPERIMENT Published by AIS Electronic Library (AISeL), 1994 K. Bødker & F. Kensing 54 stract knowledge. These levels too, should be dealt with in an iterative way. Combining the two distinctions Kensing & Munk-Madsen identify six areas of knowledge which must be developed and integrated in order for the design process to be successful. Thus the model helped us guide the project: applying various tools and techniques we set up activities, as shown in the below scenes, to ensure that knowledge within these six areas were addressed. The presentation below of tools and techniques applied in the project refers to these areas of knowledge. In the description we will focus on the techniques applied to reach given ‘ends’, in terms of certain types of insight, i.e. the knowledge areas. With each technique a set of tools are associated. In the description we primarily focus on the description tools used, i.e. what are the basic characteristics of the various description tools used to develop and maintain insight. This section is basically a reflection after the fact of what had happened in the project. There are three types of empirical data for this reflection: (1) first of all we have the design artifacts, i.e. the various descriptions and design proposals developed during the project; (2) we also have audio-taped some of the meetings in the project group; and (3) we have documented our reflections on the progress of the project by diary notes along the way. 5.1 Scene 1—Understanding Users’ Present Work We3 started the project by following the daily production of programmes. The domain was completely new to us so we spent several weeks part time (equivalent to three person weeks) getting acquainted with the workplace. Carrying a tape recorder we hung around, conducted unstructured interviews and observations of editorial meetings, journalists on research and working in the field interviewing, journalists working in their offices and in the studio preparing taped features and during broadcasting of the programme. Finally we arranged workshops around large formatted collages representing our emerging understanding of their work practice. Observations, Interviews and Workshops The description of the workplace, given in section 4 above, focuses on structural aspects—an example of area 2 knowledge. The description given below focuses on how the journalists, the secretary and the technician in various ways enacted the identified roles, used the tools in various ways, etc. in their daily work. In order to come up with these description we had to get concrete experience with users’ work practice—area 1 knowledge. This was done to qualify ourselves to participate in discussions of current work practices as well as to evaluate the relevance of the elicited structural aspects in relation to design. We observed the various activities in which the journalists and the secretary took part, e.g. the editorial meetings, accidental discussions in the secretary’s office, the work of five journalists in their offices, in the field, and in the studio. Special attention was given to the roles of the producer and the editor, who also played the role of the studio host. The observations were simultaneously documented by written notes as well as by audio recordings. We added to the recordings, by voice over, where we 8 Scandinavian Journal of Information Systems, Vol. 6 [1994], Iss. 1, Art. 2 http://aisel.aisnet.org/sjis/vol6/iss1/2 K. Bødker & F. Kensing 55 were and who were speaking or present at the time. The notes focused on the purpose of the activities, the roles played and the co-operation and the division of labour, the tools used to support the activities and the written documents that were used and produced. By focusing on these issues we built a representation of the communicative structure they engaged in. This we saw as a basis for the organization of the activities4. The observations allowed us to see how they enacted these structural properties during work. In this way the relations between area 1 and 2 types of knowledge came into play. During the observations the journalists often noted ideas for computer support in relation to the task they were engaged in. At coffee or lunch breaks these occasionally voiced ideas often led to more detached interviews or talks about the ideas mentioned and the reasons behind them. A large proportion of the tapes were transcribed and read several times. Together with the written notes and our emerging ‘inner picture’ of the editorial section, they formed the basis for our descriptions of their present work. At this point the descriptions took the form of a list of roles (see figure 2) and several large formatted collages consisting of freehand drawings combined with clips of pictures from journals (see figure 3). These clips illustrated tools or situations that related to their work. Figure 3 is an excerpt of the collages. The excerpt shows an example of a representation of the communicative structure between the editor and the producer (in Danish ‘afvikler’ and ‘producer’) where the various topics (in Danish ‘emner’) in the communication between the editor and the producer are depicted by keywords. The incoming arrows to the editor /producer show the media of communication (hand-written, typed or taped) between the editor/producer and the other journalists. These descriptions were presented at a workshop in the project group. The discussion focused on to which degree we—as designers and outsiders—had understood the essence of their work. The list of roles and the collages were subsequently corrected and added to. The focus was directed towards what they (dis-)liked in their jobs and the way in which they enacted the various roles and situations depicted in the collages, as well as towards inexpediencies and breakdowns. Whenever design ideas came up as to computer support or new FIGURE 2. Role list for journalist (translated by the authors) • Researcher (in general) • Planner • Feature producer – researcher – interviewer – author – reciter or discussion partner – office worker (reporting) • Producer or editor 9 Bødker and Kensing: DESIGN IN AN ORGANIZATIONAL CONTEXT: AN EXPERIMENT Published by AIS Electronic Library (AISeL), 1994 K. Bødker & F. Kensing 56 ways of organising the work, these were briefly discussed. The workshop session was audio taped (however only listened to, never transcribed) and notes were taken. Design goals and ideas Though the focus was on understanding their present work, some ideas for computer support came up during these types of activities. They were especially concerned with • how to improve the quality of the daily programme, • how to improve the editorial process, • how to make the editorial process transparent, • ndividual tools for the journalists and the secretary respectively. The main idea was to share data in cooperative aspects of the work, i.e. providing support for planning ahead (a kind of a calendar of ideas and planned features that often were related to specific events ahead in time). For the individual work the ideas were an ‘electronic archive’, access to a central library system as well as to external databases (news agencies). 5.2 Scene 2—Developing Design Proposals The knowledge developed so far, i.e. identified needs, inexpediencies and breakdowns (area 1 and 2 knowledge) combined with an introduction to ‘technological options’ (area 3 and 4) constituted input to the design of computer support. In developing the design proposals four techniques were used: design workshop, mapping, horizontal prototyping and vertical prototyping. In general, the products of the design activities in scene 2 were oriented towards describing or illustrating visions of computer support, in order to facilitate a discussion of the applicability or strengths and weaknesses of the design ideas. The basic idea of the activities was to enter into knowledge areas 5 and 6. In order to develop design proposals we draw upon the ‘relevant structures’ of the present work practice, i.e. knowledge area 2, as well as ‘concrete experience with users’ present work’, area 1. When describing the techniques we will highlight how this relationship between ‘relevant structures of the present work practice’ and ‘visions and design proposals’ were handled. Design Workshop In preparation for a design workshop we outlined the proposals for new tools for the individual, as well as the cooperative aspects of the work. The basic idea of the design workshop was to establish a shared framework where all design proposals—identified in scene 1 activities— were collected and related to each other. For each role identified in the role list, we described which tools were used today, and we added the proposals for new tools. This was documented by informal freehand drawings on large sheets of paper. The proposals were presented and discussed at a design workshop. In the presentation and discussion we focused on how the use of existing and new tools was related to the various documents used and produced in editing and preparing the programme. As a follow up all new tools, i.e. ideas for computer support, were put together in a coherent presentation to illustrate the functional relations or sharing of data among the various parts of the design, see figure 4. 10 Scandinavian Journal of Information Systems, Vol. 6 [1994], Iss. 1, Art. 2 http://aisel.aisnet.org/sjis/vol6/iss1/2 K. Bødker & F. Kensing 57 FIGURE 3. Excerpt from the collages (text is in Danish) 11 Bødker and Kensing: DESIGN IN AN ORGANIZATIONAL CONTEXT: AN EXPERIMENT Published by AIS Electronic Library (AISeL), 1994 K. Bødker & F. Kensing 58 FIGURE 4. The design proposal (translated by the authors) FIGURE 5. Example of a map (translated by the authors) Problem (what happened?) Reasons (why?) Conseque nces Alternatives (whishes) Actions (what can we do?) Consequences Better? paper flow (minutes, prod. overview, calendar) on loose sheets are not used personal working style, concentrating on own work, anarchy are not used nobody keeps an eye on lost ideas does not provide accessible information ideas for comming weeks are stored in a planning calendar rolling plan with permanent editors more wellplanned programmes electronic idea bank more coordinated long term planning different type of minutes no editorial meetings more structured editorial meetings all features must be approved at editorial meetings review of broadcasted features profiled programme better planned programmes yes 12 Scandinavian Journal of Information Systems, Vol. 6 [1994], Iss. 1, Art. 2 http://aisel.aisnet.org/sjis/vol6/iss1/2 K. Bødker & F. Kensing 59 Mapping of the Quality of Programmes and the Editorial Process The basic idea of mapping is to become able to identify possible actions capable of changing a problematic situation (cf. Lanzara and Mathiassen (1984) for a description of mapping). A ‘map’ is characterized as being an interpretative description of a problematic situation. We mapped problems in relation to two central issues: the quality of the programme, and the editorial process by combining a ‘diagnostic’ and a ‘virtual’ map. The two issues were closely related to the general aim of introducing new tools to improve the general quality of the daily programme, and to look for possibilities for improving the editorial process, and—as part of that—making the editorial process more transparent. Figure 5 shows a map describing problems and possible solutions in relation to the planning of the programmes, an aspect of ‘the editorial process’-problem. We presented the mapping technique to the members of the project group, and asked the journalists to prepare individual maps as ‘home work’ for a meeting. At the meeting we drew up a shared map, and based on this we had discussions about which type of problems (identified in the map) might be solved by introducing computer support, and which type of problems could not, because they were caused by e.g. inherent contradictions or time pressure in relation to the organization of work—not by inadequacy of existing tools. The discussion focused on the extent to which the visions of improving the coherence of the programme and of improving the editorial process could be realized, taking the individualistic work practice of the journalists into account. Hereby we modified the design and ‘adjusted the expectations’ towards how problems or inexpediencies might be improved, and the extend to which such improvements could be obtained by introducing computer support. Horizontal Prototyping We developed a very simple horizontal prototype5, actually a mock up, that illustrated the sharing of data through the various documents or work sheets that were created from the very beginning of outlining the programme (at the editorial meeting, e.g. in terms of the official minutes) to the final producer manuscript used during programme production. The mock up also illustrated the subsequent adding of precise times for the various features during the broadcasting of the programme, noted by the producer, and it also included the programme report, prepared the following day by the secretary. The mock up was just a Microsoft Word document, which we had prepared to simulate the key functionality and a possible user interface of the proposed system. It was presented to illustrate the vision and to facilitate a discussion of how the vision related to the elicited needs. The basic idea of the design was to eliminate situations where lack of information led to double (sometimes even triple and quadruple) typing/writing work. The design proposal also aimed at making the editorial process, carried out by the editor, transparent to all the journalists. Rather than designing a specific work flow, the point was to facilitate the oral and written communication around the emerging programme in terms of an electronic version of the sequence. As the mock-up had no functionality at all, it could not be used in real work 13 Bødker and Kensing: DESIGN IN AN ORGANIZATIONAL CONTEXT: AN EXPERIMENT Published by AIS Electronic Library (AISeL), 1994 K. Bødker & F. Kensing 60 situations, i.e. it was not possible to develop knowledge in area 6. But clearly the vision had now materialized further, and the mock-up did facilitate discussions of the relations between the vision and the work practice: the mock-up was evaluated and modified and in doing this especially the relationship between the roles of the producer and the editor, and of how that relationship differed with different pairs of journalists playing these roles, was discussed. Vertical Prototyping This technique was related towards developing and evaluating a vertical prototype of an ‘electronic archive’, one of the envisioned tools to support individual journalist work. One of the designers and a journalist developed a database and an interface to allow the journalists to enter, search and retrieve information on issues, persons, etc. in relation to features, books, articles, etc. The prototype was presented to the group, and later three journalists in turn used it in their daily work for about a week, before it was evaluated, in order to allow area 6 knowledge to develop. The evaluation indicated that the key information should be related to a person, and not an issue, because it turned out in real life situations that a specific person was always the starting point for information retrieval in the ‘electronic archive’, i.e. the evaluation required knowledge from area 1 and 6. The evaluation also showed that it was essential for the journalist’s individual work to support quick changes from one part of a system to another. In the prototype, due to the software available on their PCs it was simply too cumbersome to shift from text processing into retrieval of information in the ‘electronic archive’, and back again6. Again, the discussion related knowledge developed in areas 1 and 6. We now had a rather stable design, but for some parts of the design we felt a bit uneasy. During our observations and subsequent analysis we had noted aspects of work situations which for some parts of the design challenged the assumptions behind the vision. So we decided to go back to ‘observation and reflection mode’. 5.3 Scene 3—Making Assumptions about Work Practice Explicit To explore these uncertainties further we returned to studies of their work practice in order to contrast visions and design proposals (area 5 and 6) with concrete experience with users work (area 1). Here we used two techniques. One was to go back to observing and recording the communication involved in the production of the daily program, this time from the perspective of the editor. What turned out to be important insight from this technique was gained from the explicit assumptions and values surfaced through conversations among colleagues—assumptions and values concerning the product of the work: features and the programme as a whole as well as concerning the editorial process and work organization. The other technique used was a study of values and assumptions in relation to central aspects of the journalists’ individual work: the journalists doing research on a new topic or for a particular feature; the journalists’ use of notes and sources; and the journalists’ views on what constitutes a good feature and a good programme. In this study we partic14 Scandinavian Journal of Information Systems, Vol. 6 [1994], Iss. 1, Art. 2 http://aisel.aisnet.org/sjis/vol6/iss1/2 K. Bødker & F. Kensing 61 ularly focused on assumptions in relation to the use of artifacts in the journalists’ individual work practice, i.e. work tools such as note pads and archives and work routines such as their use of sources (cf. (Bødker & Strandgård Pedersen 1991) for an operationalization of cultural artifacts in relation to design). Perspective of the ‘Observation and Reflection Mode’ During the observations and the subsequent analysis we focused on any mismatch between the actual actions taken by the journalists and the inherent assumptions in the design proposal. We performed so to speak ‘a mental test’ of the design proposal against their actual actions, asking ourselves questions like ‘What would happen if our proposal was implemented?’ For instance we had incorporated in the design that it would be possible for all the journalists to look into the plans and options of the editor, e.g. to see which features are currently planned to be in the program and for how long time (the “sequence”). The observations clearly revealed that the editor needed to keep this kind of information to himself as it played a part in the ongoing negotiations with his colleagues (see the discussion below for further details). It would have been easy to modify the design, but instead we included it as an example of a conflict/dilemma that had to be addressed, since some journalists had asked for this kind of transparency and because it was part of the general aim of improving the coherence of the programme as a whole. After recapitulating the design proposal the results of these detailed studies of work practice were presented orally to the project group in the form of 11 assertions (see figure 6). These were presented to stimulate and provoke a discussion of the premises and consequences of the design by explicating assumptions behind the ideas for computer support as well as behind articulated and observed work practice. The assertions expressed how we, as designers and outsiders, perceived their work practice to be, as opposed to how the journalists and the secretary, as insiders, said or thought it was. Thus the objective was to test if—and where—the design was founded upon espoused or idealistic assumptions about the work, which were not reflected in the actual work practice. During the discussion we constantly focused upon contradictions or tensions between how the journalists and the secretary said or believed they worked, and our interpretation of how they worked and the implications for design. We were then able to discuss changes of the design and become aware of critical premises and fundamental values and beliefs regarding changes of the work practices. In turn, these findings had to be regarded as essential organizational decision points, if the new system was to be used as intended. Applying the Assertions—Three Examples For example, the observations showed that the journalists consider their sources to be “an integrated part of themselves” and thus highly private (assertion 2). This meant that for reasons of privacy, data about sources would never become part of a computer system, not even in a private file protected by a personal password. The consequence of assertion 2, “sources are highly private”, was that what could become part of a computer 15 Bødker and Kensing: DESIGN IN AN ORGANIZATIONAL CONTEXT: AN EXPERIMENT Published by AIS Electronic Library (AISeL), 1994 K. Bødker & F. Kensing 62 system was the names of more formal contact persons and persons who had appeared by name in the programme, which the secretary already kept in a manual file. When discussing design ideas, the journalists had placed a high value on computer support for retrieval of information on notes and sources. Given their actual use of note pads the observations made clear, that only a very small part of the notes might end up in the computer system—even if they had a laptop. Journalists take notes at many different places, during interviews (where they would never use even a laptop), at meetings, seminars, or at home (where they might), and they don’t have time to re-write them. So we could formulate the assertion “notes will remain hand-written” (assertion 3). The implication was that there would only be a very limited amount of information to retrieve, unless the journalists individually chose to change their way of taking and keeping notes7. A final example of a mismatch—between what type of computer support they initially requested and what the discussion based upon the assertions revealed to be adequate—was also related to the idea of using a future computer system to share data. As briefly mentioned above there was a conflict/dilemma between on the one hand the need of the editor to have exclusive access to plans and options for him to be able to manoeuvre among and negotiate with the individual journalists, and on the other hand the individual (competing) journalist’s interest in having access to these plans and options. Our observations revealed that this was an ongoing conflict, where journalists, some more often than others, tried to negotiate in order to promote their own feature, however basically respecting the decision of the editor (assertion 4 and 7). Our observations also revealed that some editors were not respected as much as others and sometimes even overruled by the chief editor (assertion 5). Our point in raising these types of questions was to make them aware that such conflicts/dilemmas would not be solved by introducing a new computer system—as they assumed, at least implicitly. They had to be dealt with separately, and probably FIGURE 6. 11 assertions about work in the editorial section (translated by the authors) 1. You don’t write that much 2. Sources are highly personal 3. Notes remain hand-written 4. You talk a lot about team-work, but you work very individually 5. Decisions about the programme are made at many locations 6. Unclear division of work between the editor and the producer 7. Many persons create their own vision of the programme during the day 8. There is no editorial process 9. Good ideas for features should be implemented right away 10. How can the producer use spare time in the studio? 11. You are undisciplined and hectic—and You like it. 16 Scandinavian Journal of Information Systems, Vol. 6 [1994], Iss. 1, Art. 2 http://aisel.aisnet.org/sjis/vol6/iss1/2 K. Bødker & F. Kensing 63 would have to be tackled even if they did not get any system at all. 5.4 What Happened Afterwards The design proposal was now completed and described on paper. The hardware part of the design encompassed a local area network with PCs and servers, (as opposed to the terminal based standard application system). The software part was basically a set of standard products, like word processing, e-mail and interfaces to news agencies and internal as well as external databases, complemented with specific applications for this particular section, ranging from a simple database, the “electronic archive”, to more advanced applications, like the “time recording producer manus”. The designers finally prepared a report containing a description of the needs, the design proposal, and a discussion of its consequences. The report was presented at an editorial meeting. Later it was used by the chief editor in negotiations about computer support, a process we did not take part in. 6. Discussion Our main point in giving this rather elaborate presentation of the project has been to illustrate how techniques and tools were used for the vision of computer support and the work practice to be well matched. We find that the project shows that ethnographic techniques are a valuable source for improving the product of a design process. A well-informed design process can be obtained by complementing structured descriptions with non-formal descriptions and insight into the situated actions at the workplace (Suchman 1987), and by enforcing dialogues in the design group on the relations between the visions and the work practice. In this project these dialogues were structured by relating the design proposals to familiar concepts like well-known roles or documents used in the work. The main point is to relate the design ideas to familiar concepts in the work practice (cf. “family resemblance” (Ehn 1988)), not the particular ones used in this project. Of course, one can argue that this approach is a very expensive one. As mentioned above, the three designers each spent five months part time equivalent to approximately five person months in total on the project. But research objectives were also part of the project and the section agreed to play a part in our ongoing research. Had research objectives not been part of the project we would estimate two designer months for this project. This estimate is of course difficult to justify for two reasons. First it is difficult to draw the line between research activities and design activities. Second, this project was the first where we as part of the research objectives adapted and tailored ethnographic techniques to a design context. So, two months is a guess, but the best we can give. As an overall evaluation of the research objectives of the project we can state that we found it feasible to use ethnographic techniques in a design context. The integration of various techniques still needs much consideration. As an example questions like “does the insight from using techniques with a focus on communication match the insight from using a technique with another focus?” cannot be answered by the findings from this project alone. 17 Bødker and Kensing: DESIGN IN AN ORGANIZATIONAL CONTEXT: AN EXPERIMENT Published by AIS Electronic Library (AISeL), 1994 K. Bødker & F. Kensing 64 In the following sections we will discuss two issues: how can we match computer systems to (future) work practice, and the role of descriptions in a design project. We close the discussion by relating our work to other contributions. —Matching Computer Systems to (Future) Work Practice Our project shows that it is important to design computer support for complex work settings based on a realistic vision of future work practice. In this project the journalists and the secretary formulated many ideas for computer support that were based on an implicit perception (structure) of their present work. When confronted with concrete experience of their present work developed by the designers—through the detailed studies of their work practice described in scene 1 and scene 3—some of the ideas turned out to be based on merely espoused or idealistic assumptions about the work. The leading motto in this type of work seems to be: Take users seriously, but take a deeper look! (Simonsen & Kensing 1993). The area 1 knowledge (see figure 1)developed by the designers—enabled the project group to evaluate design ideas rather thoroughly with respect to their applicability in relation to the work practice. If we had a “nice” vision, but not in accordance with the work practice, we had to make a choice: a. to abandon the vision because it was unrealistic, or b. to keep with the vision and then identify the necessary changes in e.g. work organization in order to make the vision realistic. In the description of the project we have emphasized how the designers’ insight in the work practice was used to challenge espoused or idealistic assumptions in design proposals. Of course, such insight also contributed to generating visions of computer support. We know also from other studies (by ourselves and others) that “outsider”-knowledge of users’ present work might contribute substantially to new design ideas (Simonsen & Kensing 1993, Heath & Luff 1992, Suchman & Trigg 1991). —The Role of Descriptions in the Project A distinct feature of a design process is the use of descriptions. Traditionally in software engineering and system development, descriptions are heavily oriented towards the computer system, and the perspective is the system perspective. In design in an organizational context— like the one described here—more perspectives are needed. A general objective of descriptions in early design activities is to assist in developing and maintaining an understanding of the present situation and of visions of computer support. The descriptions of the present work situation should facilitate a dialogue among designers and future users from which visions of computer support can be formulated and further developed. The visions of computer support are of course also subject for description— these might be more formal and implementation-oriented. A closer look at the descriptions developed in the three scenes shows some diversity among the descriptions. In scene 1 focusing on understanding work practice, the descriptions were oriented towards describing the present work practice—as captured by the designers. First of all, the designers needed 18 Scandinavian Journal of Information Systems, Vol. 6 [1994], Iss. 1, Art. 2 http://aisel.aisnet.org/sjis/vol6/iss1/2 K. Bødker & F. Kensing 65 to check their understanding, and second the descriptions were used to facilitate and structure a discussion of (dis-)likes, inexpediencies and breakdowns which were candidates for computer support. In scene 2, with a focus on envisioning computer support, the descriptions illustrated visions of computer support in relation to the identified “problem areas”—in various degrees of detail. So these descriptions were much more structured and formal—some even implemented in programs. The important point was, however, to relate the descriptions (i.e. the mock up and the prototype) to use-situations in order to facilitate an evaluation of the applicability of the ideas and visions. In scene 3 focusing on challenging the assumptions about work practice inherent in the various design proposals, the assumptions were confronted with provoking statements about the present work practice as understood by the designers from the detailed studies. Based on our experiences of their work practice, we were able to produce descriptions, primarily the role list and the collages, which in Kensing & MunkMadsen’s terms are structures of the work (area 2 in figure 1). The journalists and the secretary could relate to these descriptions due to the use of familiar concepts and their non-formal character. Although the descriptions missed specific aspects of the situated actions of work practice, the descriptions proved to be relevant structuring mechanisms in the discussions of (dis-) likes, breakdowns and inexpediencies in the present work (area 2) and in discussions of visions and design proposals for a new system (area 5). Also based on the initial observations of the present work practice a number of candidates for computer support were identified, as illustrated by the mock-up and the prototype (area 5 and 6). By having many differing descriptions of the present work practice and design proposals with different perspectives, emphasis, aim and level of detail we were able to ensure that design proposals were anchored in a viable vision of change. Formalism, coherence and consistency of system descriptions is of course necessary. But we tend to argue for postponing these issues till later in the development process. As shown above low structured and informal descriptions like the collages proved to be very helpful in getting the journalist to discuss their current work as well as needs for changes with us and among themselves. Incoherence or inconsistency between the various descriptions may not be a problem here; on the contrary we found that it may provide opportunities for discussions of implicit assumptions about work practice in various design proposals. —Relating to Other Contributions Above we have described how we approached this particular design endeavour. Other researchers have reported on similar approaches, i.e. with the same goal of informing the design process in complex work settings, e.g. (Bentley et al. 1992), (Heath & Luff 1992), and (Hughes et al. 1992). These studies have been labelled “ethnographically informed design”8, implying that the ethnographic study, performed by social scientists, could inform the system design, and further that the system design could be evaluated and tested by social scientists (cf. Bentley et al. 1992). 19 Bødker and Kensing: DESIGN IN AN ORGANIZATIONAL CONTEXT: AN EXPERIMENT Published by AIS Electronic Library (AISeL), 1994 K. Bødker & F. Kensing 66 In this project we have taken another approach. We have combined ethnographic studies and design into one process carried out by the same group of people. Being computer scientists with an interest in work practice studies (but clearly, we are not sociologists or ethnographers) it has been exciting and challenging. The crucial question as to whether it is possible for designers in industry—as laymen—to apply concepts and methods from social science and the humanities is a very relevant question which we are investigating in our research programme. On-going work is aimed at further investigations and development of such an approach through practical experiments and the study of practitioners while they are conducting design activities. Our research programme and our emerging design approach are closely related to the work of Goguen & Linde (1993). They propose ethnomethodology for obtaining detailed insight into the work practices of a user organization, and they propose a “zooming” method where structural methods are used to identify areas where the detailed ethnomethodological methods can be used in cost-effective ways. Hammer (1990) and Hammer & Champy (1993) suggest a business process reengineering approach, arguing that many American companies need radical changes in order to survive and improve their business. We don’t know enough of the Ford, the Taco Bell, the MBL and the other Hammer cases. But we do know that in our eight design projects, the detailed and concrete experience of those actually performing the work in question has been of great value in generating design ideas, as well as in saving money for the organizations by not trying to implement unrealistic ideas. This doesn’t exclude radical changes, however these have been changes in innovation, speed, service, and quality which in “our” organizations were considered more important that head count reduction. Finally, we do agree with Hammer in his claim that “A large portion of the population is educated and capable of assuming responsibility, and workers cherish their autonomy and expect to have a say in how the business is run” (Hammer 1990). We are only sorry that this only holds within the reengineered organization created by management and the reengineers, whereas workers’ responsibility and autonomy are considered undesirable in the reengineering process. Notes 1A condensed version of this paper was presented at The Second European Conference on Information Systems, May 30-31, Nijenrode University, and appears in the Proceedings of the conference: Baets, W., editor. Proceedings of the Second European Conference on Information Systems, Nijenrode University Publications, The Netherands Business School, Breukelen, The Netherlands 1994. 2The authors and Karen Skov Andersen, a student doing her master thesis. 3In the description ‘we’ denotes the three designers. 4In this we were inspired by the work of Winograd and Flores (1986). We used their idea of revealing the organisation through its agents’ recurrent patterns of conversation. However we didn’t think of communication in terms of Searle’s language acts. 5See Floyd (1984) for a characterisation of prototyping techniques. 6Of course, we could have used more adequate software. While the mock-up was ‘running’ on a Macintosh that we brought in, with the ‘electronic archive’ we found it important to illustrate what could be developed by the software available on the PCs in the section. 20 Scandinavian Journal of Information Systems, Vol. 6 [1994], Iss. 1, Art. 2 http://aisel.aisnet.org/sjis/vol6/iss1/2 K. Bødker & F. Kensing 67 7Today—or in a near future(?)we might have discussed the possibility of scanning (hand-)written notes. But at the time of the study it was totally out of the question as far as available technology and money was concerned. 8A term used e.g. in the title of a session at CSCW’92. Acknowledgements We thank Anette Aboulafia, Dan Shapiro, Jesper Simonsen, Jesper Simonsen, Karlheinz Kautz, Leikny Øgrim, Tone Bratteteig and Uffe Munk Hansen for comments on an earlier version of the paper presented at the 16th IRIS conference in Copenhagen. We also thank the three anonymous reviewers for their comments. Finally we thank David Bruce for helpful comments and for polishing up our English.